「固定什麼」是提問順序長出來的結果，不是兩個方法的定義；把結果背成定義，你會得到一個解釋不了現場的口訣。

一張畫得很對稱的投影片

昨天結尾留了一個流傳最廣的口訣：瀑布固定 Scope、敏捷固定 Time。今天來處理它。一樣先講故事，案例經過去識別化與合併改寫。

某次教育訓練，主題是敏捷導入，教室裡坐滿各專案調來的 PM 與工程師。講師放出那張經典的鐵三角反轉圖，兩個三角形一正一反：

Waterfall                Agile
─────────────            ─────────────
固定：Scope              固定：Time／Cost
浮動：Time／Cost         浮動：Scope

講師說：「瀑布是需求不能動，時間跟成本去配合需求；敏捷反過來，時間跟成本固定，需求浮動。記住這張圖，兩個方法的差別就懂了。」

台下抄筆記的抄筆記，拍投影片的拍投影片。這張圖畫得太對稱、太好記，好記到散場時每個人都覺得自己終於懂了。

散場後回到現場，對照一下。

隔壁那個瀑布合約案，合約附件把 Scope 列得清清楚楚，號稱一項都不能少。實際上專案中期以後，每次進度會議都在做同一件事：把某幾項功能「調整驗收範圍」「本期不納入」「移至下一階段」。到結案時，實際交付的清單跟當初的附件根本對不上——Scope 一路在砍，只是每一刀都取了別的名字。

而另一個自稱敏捷的產品團隊，口訣說 Scope 浮動、Time 固定，聽起來很符合。但他們固定的不是兩週一輪的節奏，而是一個死死的上線日：配合某個對外活動檔期，日子早就公告出去了。Sprint 再怎麼跑、功能再怎麼沒好，那天就是要上。

瀑布在砍 Scope，敏捷有死線。口訣解釋不了現場。

當時大家怎麼理解這張圖

課後大家的理解大概是：瀑布合約都簽了，Scope 當然固定；敏捷用 timebox，時間當然固定；這張圖一翻轉，差別一目了然。

每一句單獨看都有道理。合在一起，卻變成一組危險的期待。

選了瀑布，Scope 就不會少——所以隔壁案砍 Scope 的時候，沒有人把它當成變更來管理。反正「瀑布固定 Scope」，砍掉的部分只好換個名字偷偷處理。

跑了敏捷，時間就守得住——所以死線逼近的時候，沒有人重新排序 Scope。反正「敏捷固定 Time」，時間到了自然會上線。至於怎麼上線的，口訣沒有說。

把口訣當定義的問題就在這裡：它讓你以為「固定」是方法送你的保證，而不是你要自己做出來、自己付代價的承諾。

差別不在固定什麼，在先問什麼

Day 02 說過，瀑布賣的是可預測的承諾；Day 03 說過，敏捷賣的是 Feedback 與適應能力。從這兩個賣點往下推，才推得到今天的重點：

兩個方法真正的差別，是提問順序與承諾單位。

Predictive 先問：
「這個專案，全部要做什麼？」
        ↓
把答案凍成 Baseline，據此估算要多久、多少錢
        ↓
承諾單位：整個專案

Adaptive 先問：
「下一個回饋週期，最值得完成什麼？」
        ↓
在固定的節奏與有限的容量裡做選擇
        ↓
承諾單位：一輪

「固定 Scope」與「固定 Time」，是這兩種提問順序各自長出來的結果。

瀑布看起來固定 Scope，是因為它把「全部要做什麼」當成承諾的起點：Scope 是 Baseline，估算從它出發，合約因它成立。不是 Scope 不能動——Day 02 講過，動要走 Change，重新估算、重新承諾。所以隔壁案砍 Scope，其實不違反瀑布；違反瀑布的是砍的時候沒有走 Change，承諾從未重新計算，砍掉的代價沒有記在任何帳上。

敏捷看起來固定 Time，是因為它用穩定的節奏換 Feedback：每一輪承諾的不是「整個產品什麼時候好」，而是「這一輪完成什麼」。它也沒有規定不能有死線——死線本來就是商業世界的日常。真正的差別是：手上有一份持續排序的 Scope，死線那天就是一個切點，你交出排在最前面、真的完成的那個子集合；手上沒有排序，死線那天就是一場災難，你交出「每一項都做了一半」。

換句話說：

固定什麼，是承諾方式的結果；口訣把結果背成了定義。

而一旦背成定義，最重要的那件事就從視野裡消失了：不管哪一種方法，「固定」都不是免費送的。瀑布固定 Scope 的代價，是要誠實維護 Baseline 與 Change；敏捷固定節奏的代價，是要持續排序、每輪重新選擇。口訣只教你固定什麼，沒教你付什麼。

那兩個現場，是誰把口訣圓回來的

回到散場後的兩個現場。有趣的是，它們當下都沒有爆炸。

瀑布案每次「調整驗收範圍」，圈項目的都是同一位資深工程師：他知道驗收時委員真正會看哪幾項、哪些東西砍了不會被問。每一刀都挑得剛剛好。他實際上在做的，是對整案 Scope 做重新排序——用直覺做，不留紀錄，也不重新計算承諾。

敏捷團隊那邊，死線前幾週，是資深工程師憑經驗把手上的項目分成三堆：這幾個一定要完整、這幾個可以先做薄、這幾個上線那天沒有也不會有人發現。那份優先序沒有寫在任何地方，存在他腦中，隨他的判斷每天變動。

兩個現場都有人在做口訣沒教的那件事：在固定與浮動之間，做出真正的選擇。只是這個選擇沒有名字、沒有紀錄、沒有被承認——它以「經驗」的形式，住在某個人的腦袋裡。

於是教室裡的口訣可以繼續流傳，因為現場永遠有人默默把它圓回來。

這次到底誰在吸收代價？

老規矩。背了口訣的組織，名目上兩邊都很硬：瀑布案的合約 Scope 不能少（砍掉的都「只是調整」）、時程不能延；敏捷團隊的上線日不能動、人也沒有加。那「口訣與現實的落差」由誰吸收？

Scope       □   名目上一項都沒少（實際上一直在動，只是沒人記帳）
Time        □   死線如期「達成」
Cost        □
Quality     □   做薄的那些，帳單晚點寄到
Risk        □   沒有人重新評估過
人          ■   在固定與浮動之間做選擇的那個人   ← 又是這格

口訣化理解最傷的地方在這裡：它讓錯誤的期待成形。組織以為「固定」是方法給的保證，所以既不肯正式砍 Scope——那會戳破「瀑布固定 Scope」；也不肯正式動 Time——那會戳破「敏捷固定 Time」。兩個「不肯」之間的落差，只能由某個人用直覺、記憶與加班去填。

口訣越好背，期待越硬；期待越硬，人越軟。

如果沒有大神，應該留下什麼

在任何一次答應別人之前，先回答一個比「我們用什麼方法」更誠實的問題：

我們這次承諾的單位，是整個專案，還是一輪？

承諾整案，你需要的是 Day 02 的配備：Baseline 寫在大家看得到的地方、變更有出口、砍 Scope 要重新承諾，而不是換個名字偷偷做。承諾一輪，你需要的是 Day 03 的配備：有排序的 Scope、穩定的節奏、每輪重新選擇，而不是抱著死線假裝時間自然會夠。

最危險的是兩邊都要：對外用整案的口吻承諾 Scope 跟日期，對內又用「我們敏捷」安慰自己一切可以再調。這種團隊兩套配備都沒有，只剩下一個負責做選擇的人。

今日 Artifact｜「先固定什麼」對照卡

把今天收成一張兩個問題的卡片，貼在任何你正要答應的東西旁邊：

□ 這次承諾的單位是：＿＿＿＿（整個專案 ／ 這一輪）

□ 如果是整個專案——
   「全部要做什麼」寫在＿＿＿＿（Baseline 在哪）
   要砍、要改的時候，走＿＿＿＿重新承諾（Change 的出口）

□ 如果是這一輪——
   這一輪承諾完成的是＿＿＿＿（一個真的做得完的子集合）
   沒排進來的部分，由＿＿＿＿在下一輪重新排序

□ 如果有死線——
   死線那天，我們承諾交出的最小子集合是＿＿＿＿

答得出來，「固定什麼」才是你的決定；答不出來，「固定什麼」就只是投影片上的口訣，而口訣與現實的落差，會自動找上最資深的那個人。

今日一句

瀑布與敏捷的差別不在固定什麼，在先問什麼；把結果背成定義的團隊，最後真正固定下來的通常只有加班。

口訣拆掉之後，露出來的才是真正該學的東西：承諾的背後永遠有取捨。需求、時間、成本、品質——當它們不能全都要的時候，到底哪一個可以動？明天就談這件事。